Management interworking unit and a method for producing such a unit

ABSTRACT

In a process a management information unit (MI) is produced by creating models of the management interface to be interworked. Each model has objects representing managed resources. Domain knowledge, an interface and a processor create mappings between equivalent parts of the models. The models and mappings from an information conversion function (ICF) which communicates using an internal protocol with a pair of message communication functions. The message communication functions perform format conversions and communicate with the interworked interfaces.

The invention relates to a management interworking unit (MIU) and to amethod for producing such a unit. The invention relates particularly,but not exclusively, to interworking of telecommunication systems.

There are numerous situations where a management interworking unit isrequired to allow management systems to interoperate. In one typicalexample, one management system is a PABX supporting a proprietarymanagement interface and the other is a remote manager which supports astandardised interface. The MIU will provide conversion of protocol andinformation allowing the remote manager to control the PABX.

MIUs typically have a conversion function often referred to as aninformation conversion function (ICF), and interfaces often referred toas message communication functions (MCFs). An example of an MIU is thatdescribed in PCT patent specification No. WO95/23469 (BritishTelecommunications PLC). The ICF includes a mapper 44 and the MCFsincludes stacks 40 and 52. While such MIUs are generally quiteeffective, they are often difficult to produce because there is a largedegree of manual input, and they are difficult to modify or expand.

SUMMARY OF THE INVENTION

The invention is directed towards providing an improved managementinterworking unit which has a simpler construction.

Another object is to provide a method for producing a managementinterworking unit which is more efficient than has heretofore been thecase.

According to the invention, there is provided a process for producing amanagement interworking unit for a pair of management interfacescomprising the steps of:

producing an information conversion function (ICF) by:

storing a model associated with each interface, each model comprisingobjects representing managed resources, and

creating mappings including run time conversion functions betweenequivalent parts of the models; and

producing a message communication function (MCF) associated with eachmanagement interface, each MCF comprising means for performing formatconversion between the external protocol of the associated interfacesand an internal protocol for the ICF.

By creating models and subsequently creating mappings between equivalentparts of the models the production of the ICF may be automated to alarge extent. This considerably reduces the lead time in producing anMIU. Further, by separating out format conversion as an operation whichis performed exclusively by the MCF, the task of producing the MIU isbroken down in a simple manner. All internal communication uses theinternal protocol and the MCFs solely carry out the format conversionwhich is required for communication with the interworked managementinterfaces.

In one embodiment, each model comprises objects in a containmenthierarchy providing a containment context for each object. In this way,the managed resources are represented in a simple manner which reflectstheir structure.

Preferably, each object has a class defined by characteristicsindependently of the context. It has been found that by linking theclass and the context, a very effective way has been found forautomatically identifying equivalent parts of the two models. Thisallows a large degree of automation.

Preferably, the models are created at least partially automatically byloader modules. The processing operations of loader modules may becarried out very efficiently.

In one embodiment, the models are created for management interfacespecifications, and specification free text is manually converted to themodel language. This helps to ensure that any ambiguities which mayexist in the specifications are not transferred to the models.

Preferably, the mappings are between individual objects and betweengroups of objects having the same class and context, namely contextclasses. This provides a very comprehensive set of mappings.

Preferably, the mappings define context class cardinality. In oneembodiment, the mappings are created between context classes, andpreferably also between objects, and preferably also between objectcharacteristics.

In one embodiment, the characteristics include object functions (oractions), relationships, attributes, notifications, and behaviour. Ithas been found that this set of characteristics comprehensivelycharacterise each object.

Preferably, the mappings are created interactively using a graphicalinterface representing the models and the mappings. This is a verysimple and fast way of creating the mappings.

Ideally, the mappings are predicated by run time rules selected for themappings.

In one embodiment, the process has the further step of pre-compiling themodels and the mappings to a template to produce source code.

Ideally, the template is manually modified after pre-compiling and flagsare inserted in the template to differentiate automatically generatedcoded from manually generated code.

In one embodiment, searches are carried out to determine if a proposedmapping has previously been made for similar characteristics and suchmappings may be re-used.

According to another aspect, the invention provides a managementinterworking unit (MIU) for at least two management interfacescomprising:

an information conversion function (ICF) comprising:

a model associated with each interface, each model comprising objectsrepresenting managed resources, and

run time conversion mappings between equivalent parts of the models; and

a message communication function (MCF) associated with each managementinterface, each MCF comprising means for performing format conversionbetween the external protocol of the associated interface and aninternal protocol of the ICF.

This structure of MI stimulates the re-use of individual MCF/ICFcomponents.

Preferably, each model comprises objects in a containment hierarchyproviding a containment context for each object.

In one embodiment, each object has a class defined by characteristicsindependently of the context.

Preferably, the mappings are between individual objects and betweengroups of objects having the same class and context, namely contextclasses.

In one embodiment, the mappings define context class cardinality.

Ideally, mappings link context classes, and preferably also linkobjects, and preferably also link object characteristics.

In one embodiment, the object characteristics include object functionsor actions, relationships, attributes, notifications, and behaviour.

In some cases, mappings are predicated by run time rules selected forthe mappings.

In one embodiment the internal protocol includes primitives controllingstart, end, and rollback of atomic transactions in the ICF.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be more clearly understood from the followingdescription of some embodiments thereof, given by way of example onlywith reference to the accompanying drawings in which:

FIG. 1 is flow chart illustrating a process of the invention forproducing a management interworking unit (MIU);

FIG. 2 is a schematic representation of relationships between entitiesof interworked interfaces;

FIG. 3 is a schematic representation of a manner in which entities aremapped;

FIG. 4 is a sample display screen showing the manner in which the MIU iscreated; and

FIGS. 5 and 6 are is a schematic representations of the structure of anMIU.

DETAILED DESCRIPTION

Referring to FIG. 1, a process 1 is illustrated for the production of amanagement interworking unit (MIU) 10. Very briefly, the process 1involves taking source interface specifications A and B of themanagement system interfaces to be interworked. In this embodiment, thespecification A is of a GDMO (General Description of Managed Objects)interface, whereas the specification B is of a proprietary interface.The specification A is converted to an information model 4 in a Maplanguage representation by loader modules 2. The specification B isconverted to an information model 5 defined in the Map langauge byloader modules 3 which parse the specification and convert it to thesemantically equivalent Map language representation.

Instead of creating the models, they may be previously created as partof the specification or otherwise, and thus simply stored.

Once the models 4 and 5 in the Map language have been created, aprocessor 6 operates to generate the MIU 10. The processor 6 uses storedsets of domain knowledge 7 and inputs from a user interface 8 which areused to create mappings 9 during the process.

The MIU 10 comprises an information conversion function (ICF) 11 and apair of message communication functions (MCFS) 12. The ICF 11 maps theinformation contained in one of the models 4 and 5 to that contained inthe other to perform run time conversion. There is at least one ICF 11for each pair of interworked models. The MCFs 12 handle allcommunication with the external entities. The external communication isaccording to the relevant protocol, such as CMIS (Common ManagementInformation Services) or MML (Man Machine Language) primitives. There isa defined interface between each MCF 12 and the ICF 11, across whichsignals are transmitted according to an internal protocol. The internalprotocol includes only ten basic primitives.

Within the architecture of the MIU 10, there is separation of core andoptional functionality, functional distribution of the physicalarchitecture, administration, and initialisation operations.

Returning to the process 1, in one example specification A is of a Q3interface based upon an ETSI (European Telecommunications StandardsInstitute) standard management model for ATM cross-connects.Specification B is of a proprietary interface. Specification A isdescribed in GDMO and accessed via the CMIP protocol through which theoperations can be performed upon the managed objects. Specification B isbased on a proprietary object oriented information model andcommunicates using a UNIX message queue.

There is a common internal representation for objects of the informationmodels 4 and 5. The information in each interface is represented as aset of objects in a containment hierarchy. These objects are defined ina language developed for the purpose and called Map which describes notonly the information models 4 and 5, but also the mappings 9 definingthe relationships which exist between them. The loader modules 2 and 3operate on the specifications A and B, which are typically stored asASCII text to convert them into the Map description models 4 and 5. Thedescriptions which are generated may be annotated interactively usingthe interface 8 to generate additional Map statements. Alternatively,the user can directly generate the entire models 4 and 5 manually usingMap. Parts of the specification written in free text may not beconverted automatically by the loader module and so the user mustannotate the model. This ensures that any ambiguities arising from freetext are not passed into the model. An example is free textrepresentation of managed object behaviours in GDMO specifications.

The manner in which the processor 6 creates the mappings 9 is nowdescribed. These mappings include creation relationships which twinentities in the two models. Such mappings between the two models link:

(a) context classes, and within these:

(b) objects; and within these:

(c) object internal characteristics.

Regarding (a) above, each class is defined by a set of characteristicsincluding:

function (action),

relationships,

attributes (data members),

notifications, and

behaviour.

A context class is a particular class in a particular context orposition in the containment hierarchy.

Regarding (b) above, each object represents a resource managed by theassociated management system interface. They can be at widely differentlevels of the abstraction, depending on the nature of the managementrequired. One level of abstraction is cross-connect equipment, and alower-level example is a switching fabric contained within thecross-connect equipment.

Regarding (c) above each object is an instance of a class, i.e. it willhave particular characteristic values.

The Map language can describe relationships which specify that when aninstance of one context class is created in one model, then anequivalent instance of another context class should be created in theother model. These two instances are said to be twinned and therelationships are referred to as creation relationships. The processor 6creates code to support run time mappings between the instances storedin the MIU and instances stored in one of the systems being interworked.

Referring to FIG. 2, examples of the creation relationships areillustrated. One such relationship is referred to as a totalrelationship 20 between a context class 21 and a context class 22, eachhaving objects 23. Such a relationship is one-to-one. Another type ofcreation relationship is a sub-set relationship 25 in which everyinstance created in A will lead to a twin creation in B, but notnecessarily the reverse. Thus, the mappings include assertions definingcardinality.

Regarding the mapping of context classes, the Map langauge supports asimple set of assertions which are used to relate context classes in twomodels. These are described as follows:

1. Simple total relationship. Given a context class A in one model andcontext class B in another, they can be related using the expression(is-total A B). This means that whenever an instance of A is created, aninstance of B must be created and vice versa. These instances are saidto be twinned. This means that whenever an operation like get, set oraction is performed on one, its equivalent must be performed on theother.

2. Subset and predicated relationships. The expression is_subset A Bmeans that if an instance of A is created then an instance of B mustalso be created but the reverse is not necessarily true, i.e. if aninstance of B is created then an instance A is not necessarily created.Determining when to create a twin can be done using predicates. Thesecan be used, for instance, to test the values of attributes in a newlycreated instance of B to determine whether a twin instance of A shouldbe created.

3. Relating attributes or subparts of attributes. Sometimes classes intwo models may be related via an attribute which is a list or a set i.e.a twin instance exists for each member of the list or set.

4. Implicit relationships. These relationships do not imply twinningbetween two classes. Sometimes, however, an attribute in one model maybe used to uniquely identify an instance of a class within anothermodel. This is termed an implicit relationship and is supported in Mapwith the is_imp assertion.

5. Relating virtual base classes. Allowing inheritance of mappingsreduces work in the same way that allowing inheritance in classes does.

6. Many-to-one creation assertions. These occur when two or more classesin one model are to be related to the same class in another model.

7. Mappings to functional systems. Many legacy systems use functionalinterfaces such as ‘C’ language APIs or MMLs. The Map language specifiesinterface functions and asynchronous messages for handling these typesof functional interface.

Regarding the mapping of objects and their characteristics, thisinvolves describing the ways in which managed resources represented bythe objects relate to each other. This relationship is represented bythe mapping of the contained characteristics of the objects. Thefollowing are data-mapping cases involving primitives which accompanythe class mappings is_total and is_subset:

1. Mapping simple attributes. This involves describing data mappingsbetween two attributes of simple type (e.g. enumerated or integer).These mappings will generally take the form of tables for mappingenumerated types and functions for mapping other types such as integers.

2. Mapping complex attributes. Complex attributes are those involvingstructures, choices, lists or other combinations of the above. Thenotation for mapping these types is more involved.

3. Compound attribute mappings. This is where several attributes map toone attribute.

4. Mapping actions. Actions in one class may be mapped to one or moreactions in a related class. Mapping actions involve two stages. Thefirst stage is to map the action's parameters and return values. This isdone in the same way that attributes are mapped. The second stage inmapping actions is to map the critical elements of their behavioursinvolving gets, sets, creates and actions. This is a complex task.

5. Non-existent mappings for mandatory attributes. This situation occurswhen an attribute is required at object creation time but none existsbecause there is no equivalent information in the interworked interface.A default value is specified instead.

6. Uncacheable objects. This handles the situation of mappingnotifications and what happens when an object can change but does notissue a notification to the MIU. Such objects are marked as uncacheablein the MIU.

The Map language consists of a list of declarations which describe themodels 4 and 5 and the mappings 9. Map describes managed interfacesusing managed object classes, data type definitions, functions,exceptions, messages, and a containment tree.

To choose an example, a typical datatype is described as follows:

(deftype drink_machine_state (enum empty not_empty full)) This is anenumerated type declaration for the type drink_machine_state which canhave one of three values: empty, not_empty or full. Structures aredeclared in a similar fashion as are choices and lists. In addition,there are certain basic types such as integer, natural, string, real,boolean and reference (for referencing other managed objects).

The following is an example of a mapping in the Map language.This-mapping relates to the diagram of FIG. 3.

(is_total GEquipment G12Equipment (=GType 12) . . . )

In this example, two models have taken a different approach to modellingthe same real-world resources. One has chosen to model the set of allGEquipment objects using a single class called GEquipment. The othermodel has modelled the same type of resources using three differentclasses: G12Equipment, G14Equipment and G16Equipment which are lessgeneral than GEquipment. GType is an attribute in GEquipment. When, forexample, an instance of GEquipment is created with GType=12, its twinwill be an instance of G12Equipment class.

When GType=24, there is no equivalent mapping. The default decision fora predicated mapping is not to create a twin. The attributes which maybe tested are those that must be supplied at creation time, i.e.mandatory attributes.

The general format of an is_total relationship is as follows:

(is_ total source-context-class target-context-class predicate(attribute-maps . . . ) ;; Data mappings attributes (action-maps . . . );; Mappings for attributes (notification-maps . . .)) ;; Mappings fornotifications

The attribute-maps statement consists of a list of maps statements whichhave the general form for simple attribute mappings:

(maps <attribute-component> <attribute-component>

(down <maptable>|<function>)

(up <maptable>|<function>))

There are two mappings, one in a downward direction, one in an upwarddirection. These can be described by means of either a maptable whichprovides explicit translations for enumerated types or by a functionwhich is written programmatically, like an action behaviour, or drawnfrom a standard set of functions, e.g. per-hour-to-per-minute. Thesepredefined functions could potentially be provided in a library ofseparate Map modules. The simplest form of the maps statement is wheretwo attributes are involved, both of which are enumerated types andmaptables are used to specify downward and upward mappings. An exampleof this is illustrated below.

This example involves mapping simple attributes such as enumerated typesor integers. Consider the following types used to describe theattributes drink_machine_state and vending_machine_state:

(deftype drink_machine_state_type (enum run_out ok low)) (deftypevending_machine_state_type (enum empty operational))

In order to map an attribute of type drink_machine_state_type to anattribute of type vending_machine_state_type, we use the followingexpression.

(attribute-mappings (maps drink_machine_state vending_machine_state ;;Mapping drink_machine_state down to ;; vending_machine_state (down(maptable (run_ out empty) ;; run_out maps to empty (ok operational)(low operational) ;; Mapping vending_ machine_state back up to ;;drink_machine_state (up (maptable (empty run_out) ;; empty maps torun_out (operational ok) )) ))

Mapping tables are not always sufficient for describing a mapping. Wheremore flexibility is required, mapping functions use the same simpleprogrammatic syntax for describing conversions. Consider the problem ofmapping from an integer attribute X to an integer attribute Y, The valueof Y is always double that of X unless X exceeds 128, in which case Yalways takes the value 256. In Map this would be implemented as.

(maps X Y (down ;; Declare a function with a single parameter ;; paramwill automatically be instantiated with (func (param) (var integer ?rval) ;; ;; Multiply param (X) by 2 and ;; assign to variable ? rval ;;(assign ? rval (* param 2)) ;; ;; if ? rval exceeds 256 then ;; let ?rval = 256 ;; (if (> ? rval 256) (assign ? rval 256) nil ;; else ) ;; ;;Return the final result, ?rval ;; (return ? rval) ) (up ;;; function todo the opposite of the downward function) )

It is possible to use predefined or previously defined functions formapping. For instance, if the values of attribute X mapped straight toattribute Y and vice versa the mapping could be defined as:

(maps X Y

(down

(function identity))

(up

(function identity)))

The compiler ensures that the number of arguments for the predefinedfunction match those of the mapping (in this case a single argument isrequired in each direction).

The processor 6 has a compiler which generates skeletal source code forthe MIU 10. Code generation occurs in two stages, namely pre-compilingfor generation of a code template, and conversion of the code templateinto a code output. The code template allows a user to view theautomatically generated source code and to customise it by addition ofhand-written code. Flags are used to differentiate between the two typesof code so that user code is not over-written by the compiler. Thecompiler generates source code of a high level language such as C++ aswell as IDL code. Mapping features implemented include processing ofis_total and is_subset class mappings including aspects such as:

Implementing mapping predicates,

Mapping ‘context classes’,

Mapping of class creation,

Propagation of simple/choice/structured data mappings for attributesboth to and from the Managing and Managing Systems,

Propagation of actions including parameter and return value mapping,

Mapping set-valued attributes and action parameters,

Mapping of notifications raised by the Managed System.

In addition to a compiler, the processor 6 also uses the user interface8 as a Map model editor and a mapping definition editor. Referring toFIG. 4, a tool bar 30 displayed by the user interface 8 is illustrated.This tool bar allows the user to select the source and target models tobe mapped from the list of models loaded into the system. The screenshown in FIG. 4 is at the beginning of a mapping session in which amapping has just been drawn between the class FABRIC in model A and theclass FAB in model B. This is done simply by clicking on “CreateMapping” in the button and then selecting the source and target classesfor the mapping. A line is then displayed to depict the mapping and thewindow shown top-right of the figure appears. This is referred to as anassertion window and it allows the user to specify the type and thecontent of the mapping. Normally the user will begin by specifying-thenature of the mapping at a class level and in this example it involveschoosing a mapping as being is_total or is_subset. Other options couldbe available such as is_imp, is_total_rev, or is_subset_rev. Thepredicate, to describe the run time conditions under which the twinningis to be formed, must be specified. After hitting the predicate buttonthey can type the predicate directly in an editor window. At any stageduring modelling or mapping, the user may decide to compile the systemdown to source code using the menu illustrated.

In summary, the process carried out by the processor 6 could be set outbriefly in the following table:

STEP 1 Describe the managed interfaces to the two systems beinginterworked. In general these descriptions will be generatedautomatically from the existing system specification. For instance, afile containing a GDMO description is imported using a converter whichconverts the specification to Map. If it is not possible to do this,then the user will have to describe the managed interface manually usingthe MIU CE's modeller toolbar.

STEP 2 Describe in the Map language the mappings between the twosystems. Some of these will be specified by hand, others can be inferredautomatically by the Creation Environment.

STEP 3 Compile the resultant Map description of the mappings down tocode templates for the MIU. Code templates contain the outline of finalMIU source code. They allow the user to see what this code output willlook like. Code templates also allows the user to add their ownhandwritten code to supplement the autogenerated code (See step 4).

STEP 4 Add handwritten source code where necessary and generate finalcode output. Using code templates means that even if the mappings arerecompiled the handwritten parts will not be overwritten.

Referring to FIGS. 5 and 6, the MIU 10 which is created is shown in moredetail. FIG. 5 shows the MIU broken into the MCFs and the ICF. The MCFsabstract the specifics of the particular communication protocols (e1 ande2). They use a homogeneous set of internal generic managementprimitives to communicate with the ICF over interfaces i1 and i2. Theinternal structure of the ICF which is used to effect the mappingsbetween the systems at runtime is important. The purpose of the MIU CE(Creation Environment) is to provide support for a process to build theICF portion of an MIU. The internal protocol which crosses the internalreference points 11 and 12 includes the following primitives:

GET Get is specific to object based models and retrieves the value of anattribute. It is analogous to the CMIS M-GET service element. SET Set isspecific to object based models and sets the value of an attribute. Itis analogous to the CMIS M-SET service element. CREATE Create isspecific to object based models and creates a new object instance. It isanalogous to the CMIS M-CREATE service element. DELETE Delete isspecific to object based models and deletes an object instance. It isanalogous to the CMIS M-DELETE service element. FUNCTION Functioninvokes a function across the interface. Such a function could be a CMISM-ACTION or could be an MML command to a managed resource. Function canbe synchronous in which it waits for the result of the function orasynchronous in which it doesn't wait. NOTIFY Notify intercepts an eventreport from the interface. Such an event report could correspond to aCMIS M-EVENT-REPORT or an asynchronous message from the managedresource. RECEIVE Receive enables the ICF to receive data from theinterface. It would be used where the ICF expect's an asynchronousresponse from an external entity. The receive primitive blocks the ICFwaiting for the response. START- This primitive enables a set ofprimitives to MIU- be invoked as an atomic transaction. If anTRANSACTION error occurs during one of the operations which make up thetransaction then the previous operation can be undone to revert back tothe previous state. END_MIU_(—) This primitive denotes the end of theTRANSACTION transaction and indicates that the transaction wassuccessful and should be committed. ABORT_(—) This primitive is used toterminate a MIU_(—) transaction in which one of the operationsTRANSACTION was unsuccessful. It is used to rollback all the operationsperformed during the transaction and return the systern to its previousstate.

RECEIVE

Receive enables the ICF to receive data from the interface. It would beused where the ICF expects an a synchronous response from an externalentity. The receive primitive blocks the ICF waiting for the response.

START-MIU-TRANSACTION

This primitive enables a set of primitives to be invoked as an atomictransaction. If an error occurs during one of the operations which makeup the transaction then the previous operation can be undone to revertback to the previous state.

END_MIU_TRANSACTION

This primitive denotes the end of the transaction and indicates that thetransaction was successful and should be committed.

ABORT_MIU_TRANSACTION

This primitive is used to terminate a transaction in which one of theoperations was unsuccessful. It is used to rollback all the operationsperformed during the transaction and return the system to its previousstate.

The MCFs perform the format conversion to these primitives from therelevant external protocol by hard-coded rules.

The MIU provides the runtime support necessary for system interworking.In order to effect the mappings the MI architecture supports someparticular runtime structures including:

A Twinning Table—Given a reference to an object in the MIU it willreturn a reference to the equivalent object in the managed systems andvice versa.

An expected events queue—This holds a list of events which are expected,when they are to arrive and what action to take when they arrive.

The Map compiler generates source code for these structures and allrelated mappings. Where required the MI can be generated so that itstores its objects persistently using a database. The key to the Mapcompiler is that it allows flexibility in the type of source code itoutputs. The user can insert ‘tags’ in the map code allowing him or herto include portions of handwritten source code. This means that even ifthe mappings change the user's handwritten source code annotations willnot be overwritten. Allowing flexible code generation is a greatadvantage. The invention does not require an expensive, proprietaryruntime environment, because it can potentially generate code that willfit into a variety of runtime environments or else provide a‘lightweight’ standalone runtime MIU.

The MCF and ICF components of the MIU 10 use CORBA IDL interfaces tocommunicate with other components. These interfaces are based onprimitives for retrieving and setting values of attributes, creating anddeleting object instances, invoking a function across the interface,event reporting, enabling the ICF to wait until specified data isreceived from the interface, enabling a set of primitives to be invokedas an automatic transaction, denoting the end of the transaction, androlling back a transaction.

There may additionally be primitives for start-up. As can be seen fromFIG. 3, each of the component objects contains at least one process andthere is also a server process for the DBMS. Both the managed andmanaging ICFs are DBMS clients and manipulate the managed objects in theMIB, which is stored in the DBMS. Both the managing and the managed ICFservers act as distinct database clients and so are independent of eachother.

Referring again to FIG. 6, the processes and IDL interfaces of the MIU10 are illustrated. The ICF 11 acts as a dispatcher for the managed andthe managing ICF interfaces. An MCF 12 is not allowed to associatedirectly with either the managed or managing ICF interfaces, but insteadassociates with the ICF interface, which then passes back a reference tothe appropriate managed or managing ICF interfaces. This is done toensure that the MCFs in an MIU are associated with the correctinterfaces.

It will be appreciated that the invention provides a process forproducing an MIU which automates the task to a large extent, while atthe same time allowing large degree of user interaction to provide thenecessary flexibility. The structure of the models and the manner inwhich the mappings are generated allows the degree of automation, and inaddition provides a simple structure which may be easily understood bythe user for manual annotation and later modification. Further, becausethe structure of the MIU is simple, it may be easily modified to eithertake account of changes in management interfaces which are alreadyinterworked, or to add additional interworking capability. The fact thatthe format conversion from the external to the internal protocol isperformed by the MCFs separately from the ICF is an important feature asit results in a definite boundary between the MCFs and the ICF. Further,within the ICF, the model and mappings structure is relatively simpleand allows easy modification.

The invention is not limited to the embodiments hereinbefore described,but may be varied in construction and detail.

What is claimed is:
 1. A process for producing a management interworkingunit for a pair of management interfaces comprising the steps of:producing an information conversion function (ICF) by: storing a modelassociated with each interface, each model comprising objectsrepresenting managed resources, providing a containment context for eachobject in a containment hierarchy, classifying each object with a classdefined by characteristics independent of the containment context, andcreating mappings between individual objects and between groups ofobjects having the same class and context from the stored models,including run time conversion functions between equivalent parts of themodels; and producing a message communication function (MCF) associatedwith each management interface, each MCF comprising means for performingformat conversion between the external protocol of the associatedinterfaces and an internal protocol for the ICF.
 2. A process as claimedin claim 1, wherein the models are created at least partiallyautomatically by loader modules.
 3. A process as claimed in claim 1,wherein the models are created from management interface specifications,and specification free text is manually converted to the model language.4. A process as claimed in claim 1, wherein the mappings define contextclass cardinality.
 5. A process as claimed in claim 1, wherein mappingsare created between context classes.
 6. A process as claimed in claim 1,wherein mappings are created between objects.
 7. A process as claimed inclaim 1, wherein mappings are created between object characteristics. 8.A process as claimed in claim 7, wherein the object characteristicsinclude object functions, relationships, attributes, notifications, andbehavior.
 9. A process as claimed in claim 1 wherein the mappings arecreated interactively using a graphical interface representing themodels and the mappings.
 10. A process as claimed in claim 1, whereinmappings are predicated by run time rules selected for the mappings. 11.A process as claimed in claim 1, wherein searches are carried out todetermine if a proposed mapping has previously been made for similarcharacteristics and such mappings may be re-used.
 12. A managementinterworking unit (MI) for at least two management interfacescomprising: an information conversion function (ICF) comprising: a modelassociated with each interface, each model comprising objectsrepresenting managed resources, each object having a containment contextin a containment hierarchy, and each object being defined by acharacteristic independent of the containment context, and means forcreating mappings between individual objects within groups of objectshaving the same class and context from stored models including mappingrun time conversion functions between equivalent parts of the models;and a message communication function (MCF) associated with eachmanagement interface, each MCF comprising means for performing formatconversion between the external protocol of the associated interface andan internal protocol of the ICF.
 13. A management interworking unit asclaimed in claim 12, wherein the mappings define context classcardinality.
 14. A management interworking unit as claimed in claim 12,wherein mappings means link context classes.
 15. A managementinterworking unit as claimed in claim 12, wherein mappings means linkobjects.
 16. A management interworking unit as claimed in claim 12,wherein mappings means link object characteristics.
 17. A managementinterworking unit as claimed in claim 16, wherein the objectcharacteristics include object functions or actions, relationships,attributes, notifications, and behavior.
 18. A management interworkingunit as claimed in claim 17, wherein mappings are predicated by run timerules selected for the mappings.
 19. A management interworking unit asclaimed in claim 17, wherein the internal protocol includes primitivescontrolling start, end, and rollback of atomic transactions in the ICF.20. A process for producing a management interworking unit for a pair ofmanagement interfaces comprising the steps of: producing an informationconversion function (ICF) by: storing a model associated with eachinterface, each model comprising objects representing managed resources;providing a containment context for each object in a containmenthierarchy; classifying each object with a class defined bycharacteristics independent of the containment context; creatingmappings between individual objects and between groups of objects havingthe same class and context from the stored models, including ran timeconversion functions between equivalent parts of the models;pre-compiling the models and the mappings to a template to producesource code; and modifying said template manually after pre-compilingwhere necessary; and producing a message communication function (MCF)associated with each management interface, each MCF comprising means forperforming format conversion between the external protocol of theassociated interfaces and an internal protocol for the ICF.
 21. Aprocess as claimed in claim 20, wherein the models are created at leastpartially automatically by loader modules.
 22. A process as claimed inclaim 20, wherein the models are created from management interfacespecifications, and specification free text is manually converted to themodel language.
 23. A process as claimed in claim 20, wherein themappings define context class cardinality.
 24. A process as claimed inclaim 20, wherein mappings are created between context classes.
 25. Aprocess as claimed in claim 20, wherein the mappings are created betweenobjects.
 26. A process as claimed in claim 20, wherein mappings arecreated between object characteristics.
 27. A process as claimed inclaim 26, wherein the object characteristics include object functions,relationships, attributes, notifications and behavior.
 28. A process asclaimed in claim 20, wherein the mappings are created interactivelyusing a graphical interface representing the models and the mappings.29. A process as claimed in claim 20, wherein mappings are predicted byrun time rules selected for the mappings.
 30. A process as claimed inclaim 20, wherein searches are carried out to determine if a proposedmapping has previously been made for similar characteristics and suchmappings may be reused.
 31. A process as claimed in claim 20, whereinflags are inserted in the template to differentiate automaticallygenerated code from manually generated code.
 32. A managementinterworking unit (MIU) for at least two management interfacescomprising: an information conversion function (ICF) comprising: a modelassociated with each interface each model comprising objectsrepresenting managed resources, each object having a containment contextin a containment hierarchy and each object being defined by acharacteristic independent of the containment context, means forcreating mappings between individual objects within groups of objectshaving the same class and context from stored models including mappingrun time conversion functions between equivalent parts of the models,means for pre-compiling said model and said mappings to a template toproduce source code, and means for modifying said template after saidpre-compiling means where necessary; and a message communicationfunction (MCF) associated with each management interface each MCFcomprising means for performing format conversion between the externalprotocol of the associated interface and an internal protocol of theICF.
 33. A management interworking unit as claimed in claim 32, whereinthe mappings means define context class cardinality.
 34. A managementinterworking unit as claimed in claim 32, wherein the mappings meanslink context classes.
 35. A management interworking unit as claimed inclaim 32, wherein the mapping means link objects.
 36. A managementinterworking unit as claimed in claim 32, wherein the mapping means linkobject characteristics.
 37. A management interworking unit as claimed inclaim 36, wherein the object characteristics include object functions oractions, relationships, attributes, notifications and behavior.
 38. Amanagement interworking unit as claimed in claim 32, wherein mappingsare predicted by run time rules selected for the mappings.
 39. Amanagement interworking unit as claimed in claim 32, wherein theinternal protocol include primitives controlling start, end and rollbackof automatic transactions in the ICF.
 40. A management interworking unitas claimed in claim 32, wherein there is provided means for insertingflags in the template to differentiate automatically generated code frommanually generated code.